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REMARKS 

This amendment is being filed along with a Request for Continued Examination 
(RCE) application in response to the final Office Action having a mailing date of September 30, 
2005. Claims 1, 8, 16-17, 23, and 30 are amended as shown. New claims 33-37 are added. No 
new matter has been added. With this amendment, claims 1-37 are pending in the application. 

The undersigned attorney would very much appreciate having a chance to further 
discuss the claim amendments and references with the Examiner via telephone, after the 
Examiner has had a chance to review this amendment. It is hoped that such a telephone 
conversation would allow the undersigned attorney to help facilitate examination of the claims 
and to further convey the distinctive features of the claims, before the Examiner substantively 
updates his prior art search and issues a new Office Action. It is further hoped that the telephone 
conversation would allow the applicants and the undersigned attorney to move the prosecution of 
the present application forward towards allowance in a positive and cooperative manner with the 
Examiner. 

In the final Office Action, the Examiner rejected claims 16-32 under 
35 U.S.C. § 103(a) as being unpatentable over Guetz (U.S. Patent No. 6,091,777) in view of 
Doty (U.S. Patent No. 6,795,863). For the reasons set forth below, the applicants respectfully 
disagree with these rejections and request that the pending claims be allowed. 

I. Discussion of the applicants' disclosed embodiments 
A disclosed embodiment will now be discussed in comparison to the applied 
references. Of course, the discussion of the disclosed embodiment, and the discussion of the 
differences between the disclosed embodiment and subject matter described in the applied 
references, do not define the scope or interpretation of any of the claims. Instead, such discussed 
differences are intended to merely help the Examiner appreciate important claim distinctions 
discussed thereafter. 

As disclosed in the present application and discussed in prior responses to Office 
Action, various embodiments of the present invention allow multiple simultaneous output video 
streams to be provided to respective multiple client devices. The output video streams have 
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different characteristics (such as bit rate, encoding format, frame rate, resolution, etc.), such that 
server-side selection can be performed to select an optimum (or otherwise customized) output 
video stream to send to each client device. This customization of each output video stream 
accounts for the fact that the client devices may have different capabilities and to account for 
varying channel conditions. In at least one embodiment, the characteristics of the output video 
streams can change or otherwise adapt ("on the fly" during transmission) to dynamically 
changing client device characteristics and/or channel conditions. 

As an example, the simultaneous output video streams can have different bit rates 
from one another, such that client devices with lesser bit rate capabilities receive the lower bit 
rate output video streams, while client devices with better bit rate capabilities receive the higher 
bit rate output video streams. Thus, at least some of the simultaneous output video streams have 
a bit rate that exceeds a bit rate capability of a least-capable client device . 

There are other features of the disclosed embodiments. For example, the input 
video stream (from which the multiple simultaneous output video streams are derived) can be 
selected from a compressed digital format and an uncompressed format. If the input video 
stream is in the compressed digital format, an embodiment de-compresses the input video stream 
into a de-compressed format at the server, and then during the transcoding process at the server, 
re-compresses the input video stream into the simultaneous multiple output video streams. 

In one example embodiment, the simultaneous output video streams have 
different encoding/compression formats from one another. For example, some output video 
streams may have an MPEG format, while other output video streams may have a non-MPEG 
format. See, e.g., original claim 3. 

II. Discussion of Guetz 

Guetz has been extensively discussed in prior responses to Office Actions, and the 
applicants still believe that Guetz does not disclose, teach, or suggest the features provided by 
the present applicants' embodiments. Guetz provides a "layered" technique of transmitting 
video that is different than the "multiple output stream" techniques provided by the present 
applicants. 
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Specifically, Guetz discloses transmitting a single output video stream having 
multiple layers. In this "layered" approach, the client devices (rather than the server) determine 
which of the transmitted layers to select for presentation. That is, the client devices determine 
the level of visual image desired and select the layers to be utilized. See, e.g., column 5, lines 
64-66 of Guetz. Therefore, it is clear that the server of Guetz is not involved in the selection of 
the specific layers to be utilized at the client devices. 

A feature of Guetz that has been extensively discussed by the present applicants is 
that Guetz provides a single output video stream having a bit rate that is commensurate with the 
least capable client. See, e.g., column 6, lines 34-37 and the Abstract of Guetz. As defined in 
the 2005 version of the Merriam- Webster Online Dictionary, the term "commensurate" means 
"corresponding in size, extent, amount, or degree." This "commensurate" feature of Guetz is 
indisputable and is a requirement of Guetz — the bit rate received by all client devices in Guetz is 
the same for all client devices and corresponds to the bit rate capability of the least capable client 
device . 

The Examiner has admitted in the final Office Action that Guetz does not disclose 
the simultaneous transmission of output video streams. Guetz also does not disclose, teach, or 
suggest other features. 

For example, Guetz does not provide simultaneous multiple output video streams 
having different encoding formats , including both MPEG and non-MPEG formats. Indeed, it 
appears that Guetz is completely silent as to the specific encoding format used by his output 
video stream. Moreover, it is not possible for Guetz to provide different encoding formats for 
simultaneous multiple output video streams, since Guetz does not provide simultaneous multiple 
output video streams to begin with. 

As another example, Guetz does not receive an input video stream in a 
compressed digital format, de-compress that input video stream, and then re-compress the 
de-compressed video stream into the multiple simultaneous output video streams. Instead, Guetz 
receives an NTSC input, which is an analog signal (and not a digital signal, whether compressed 
or un-compressed). See, e.g., Figure 1 and column 10, lines 45-46 of Guetz. 
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III. Discussion of Doty 

To supply the missing teachings of Guetz, specifically the feature of simultaneous 
output video streams having different bit rates that correspond to both multiple different client 
device capabilities and channel conditions, the Examiner has cited Doty. Doty involves a system 
to send emails to client devices, with the email having an embedded video screen for viewing 
streaming video. See, e.g., the Abstract of Doty. However, Doty fails to cure the deficiencies of 
Guetz based on a number of reasons, some of which are discussed below. 

First, Doty does not qualify as prior art in the manner used by the Examiner. That 
is, Doty's earliest filing date is based on the August 10, 1999 filing date of its parent provisional 
application (U.S. Provisional Application Serial No. 60/147,815). The undersigned attorney has 
thoroughly reviewed a copy of this provisional application, and cannot find anything disclosed 
therein that involves different bit rates that correspond to both multiple different client device 
capabilities and channel conditions . 

Accordingly, the earliest date of Doty that can be relied upon by the Examiner as 
disclosing this feature is August 10, 2000, which is the filing date of Doty's issued patent. 
Because this August 10, 2000 filing date is subsequent to the February 10, 2000 filing date of the 
preset application (and also subsequent to the original priority provisional filing date of the 
present application), Doty does not qualify as prior art. 

Second, Doty (the issued patent, whether or not qualifying as prior art) does not 
appear to disclose, teach, or suggest different bit rates that correspond to both client device 
capabilities and channel conditions. Rather, the bit rates of Doty are based solely on client 
device characteristics . See, e.g., column 8, lines 45-58 of Doty. 

Third, while it appears that Doty uses server-side determination of which output 
video stream to send to each client device, Doty does not derive such output video streams from 
a digital (whether compressed or un-compressed) input stream. Rather, Doty's input signal is an 
analog signal. See, e.g., items 12 and 26 in Figure 1 of Doty. Hence, Doty cannot and does not 
perform the de-compression and re-compression as discussed above with respect to the present 
applicants' embodiments. 
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Fourth, Doty does not perform changes in the frame rate, bit rate, resolution, 
spatial bandwidth, color depth, and the like during transmission and in response to changes in 
either or both channel conditions or client device characteristics. Clearly, Doty does not take 
channel conditions into account. Furthermore, Doty clearly does not provide any mechanism for 
adjusting or otherwise changing characteristics of his video streams during transmission in order 
to take into account changes at the client device and/or channel conditions. It is easy to see why 
Doty does not update his video streams — Doty provides a video screen that is embedded in an 
email. If the resolution of the video stream is to be changed during transmission, then a new 
email having an appropriate different video screen has to be sent — the client devices of Doty 
would therefore be flooded with irritating new emails with embedded video screens each time 
the resolution or other characteristic of the video stream has to be changed. 

IV. Discussion of Liu 

Liu (U.S. Patent No. 5,970,233) was cited by the same Examiner in another 
co-pending application (U.S. Patent Application Serial No. 09/502,409) owned by the same 
assignee as the present application. Specifically, Liu was combined with Guetz and was cited for 
allegedly disclosing multiple simultaneous output video streams having different formats. 
However, it is believed that Liu (like Doty) fails to cure the deficiencies of Guetz. 

First, the output video data of Liu does not have different encoding formats 
including both MPEG and non-MPEG formats. Rather, Liu simply discusses color encoding 
(such as YUV or RGB color encoding), and makes no mention whatsoever as to whether his 
output video data having this color encoding is in MPEG format and/or non-MPEG format, and 
whether his format of the output video data is compressed or un-compressed. 

Second, Liu is completely silent as to whether his input video stream is 
compressed or un-compressed. Hence, Liu does not disclose, teach, or suggest the 
de-compression and re-compression as discussed above with respect to the present applicants' 
embodiments. 

Third, it is unclear from Liu whether it is server-side or client-side determination 
of which output video data to send to each recipient PC 330 and PC 310. Indeed, it appears that 
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Liu does not even involve a server-client architecture, since his Figure 3 shows the PCs 310 and 
330 connected to a PC 320 via bus lines 311 and 331. At most, Liu might be considered as 
providing server-side determination, if the PC 320 is construed as a "server" — but Liu does not 
appear to disclose, teach, or suggest that this PC 320 makes any sort of determination or 
selection. Rather, its inputs are hard wired into and hard wired out of the respective 
encoders/decoders — thus, no selection or determination need be performed. See, e.g., Figure 4 
of Liu. 

V. Reasons why Doty and/or Liu cannot be combined with Guetz 
Doty cannot be combined with Guetz because of at least the following reasons 
and as discussed above: 

A. Doty, if hypothetically combined with Guetz, will be forced to provide all 
of his output video streams with the same bit rate, commensurate with the least capable client. 
The same bit rate commensurate with the least capable client is a requirement of Guetz, and 
therefore, any reference combined with Guetz will need to accommodate this requirement. As 
explained above and in contrast, the present applicants' disclosed embodiments provide different 
bit rates, including bit rates that exceed the bit rate capability of the least capable client device. 

B. Doty uses server-side determination of which output video streams to send 
to the client device. In contrast, Guetz uses client-side determination of which layers to select. 
Hence, a person skilled in the art would not look to the server-side solution of Doty to cure the 
deficiencies of Guetz client-side solution. 

C. Doty does not provide the capability to select output video streams based 
on channel conditions, and further does not provide the capability to dynamically change/update 
the output video streams based on client device characteristics and channel conditions that both 
change during transmission. Guetz provides some capability to do this. However, combining 
Doty with Guetz will force Doty to update his output video streams, and as explained above, 
force Doty to send out multiple emails with different video screens each time the video stream is 
to be updated. This is an impractical modification of Doty and is clearly not suggested in Doty 
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because his client devices will receive multiple annoying emails each time the video stream 
needs to be updated. 

Liu cannot be combined with Guetz because of at least the following reasons and 
as discussed above: 

A. Liu, if hypothetically combined with Guetz, will be forced like Doty to 
provide all of his output video streams with the same bit rate, commensurate with the least 
capable client. The same bit rate commensurate with the least capable client is a requirement of 
Guetz, and therefore, any reference combined with Guetz will need to accommodate this 
requirement. As explained above and in contrast, the present applicants' disclosed embodiments 
provide different bit rates, including bit rates that exceed the bit rate capability of the least 
capable client device. 

B. Both Liu and Guetz, even if hypothetically combined, do not provide 
compressed input video, de-compress that input video, and then re-compress to provide the 
output video streams. Furthermore, both Liu and Guetz do not disclose, teach, or suggest that 
their output video streams have different encoding formats, including both MPEG and non- 
MPEG formats. 

C. As explained above, Liu does not disclose a client-server architecture. 
Even if the PC 320 is construed to be a "server," the PC 320 does not make any determination or 
selection of which output stream to send to a particular recipient. Furthermore, a person skilled 
in the art would not look to the quasi-server solution of Liu to cure the deficiencies of the 
client-side solution proposed by Guetz. 

VI. Discussion of the claims 

Independent claims 16 currently recites " server-side code to select simultaneous 
output video streams having the different bit rates that correspond to both multiple different 
client device capabilities and channel conditions." It is believed that this recitation already 
distinguishes over both Guetz and the non-prior art Doty (if assumed to be prior art), as well as 
distinguishing over Liu, whether singly or in combination. 
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For example, Guetz does not provide the recited server-side code, since he 
provides client-side selection-as explained above, the server-side solution of Doty cannot be 
used to cure the client-side solution of Guetz. 

Next, the simultaneous output video streams with different bit rates are not 
provided by Guetz, and the output video streams of Doty (if assumed to be prior art) only 
correspond to client device capabilities and not to channel conditions. Moreover and as 
explained above, if Doty is combined with Guetz, Doty (as well as Liu) will be forced to provide 
a single/same bit rate for his output video, with that bit rate being commensurate with the least 
capable client device. Thus, the "different bit rates" limitation of claim 16 is not met. 

Nevertheless, to facilitate prosecution, claim 16 is amended as shown to recite the 
feature of —at least some of the simultaneous output video streams having a bit rate that exceeds 
a bit rate capability of a least-capable client device—. This feature clearly distinguishes over 
Guetz, and would distinguish over Guetz combined with Doty (or Liu) since these other 
references would be forced to adopt the single bit rate commensurate with the least capable client 
device that is required by Guetz. Accordingly, claim 16 is now further allowable over the cited 
references. 

Independent claim 23 currently recites " server selection of simultaneous output 
video streams having the different bit rates that correspond to both multiple different client 
device capabilities and channel conditions." As explained above, these features are not disclosed 
by Guetz or the non-prior art Doty (and/or Liu), whether singly or in combination. Accordingly, 
claim 23 is believed to be presently allowable. 

However, to also facilitate prosecution, claim 23 is amended to recite —at least 
some of the simultaneous output video streams having a bit rate that exceeds a bit rate capability 
of a least-capable client device—. Since this feature is clearly not disclosed, taught, or suggested 
by Guetz and/or by the other references when combined with Guetz, claim 23 is further 
allowable. 

Claim 23 is further amended to recite -multiple different— encoding formats 
respectively for the output video streams. These features are clearly not disclosed, taught, or 
suggested by Guetz. 
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Certain dependent claims will be discussed next. These dependent claims recite 
subject matter that distinguishes over the cited references, whether singly or in combination. 

Dependent claim 17 is amended to recite -changes to the spatial bandwidth of the 
simultaneous output video streams during transmission—. Doty and Liu do not change spatial 
bandwidth during transmission. Guetz does not provide the recited simultaneous output video 
streams. Accordingly, claim 17 is allowable. 

Dependent claim 30 recites updating characteristics of the simultaneous output 
video streams, in response to changes in either or both channel conditions or client device 
characteristics during transmission. Again, Guetz does not provide the recited simultaneous 
output video streams, and Doty/Liu do not perform the recited updating. Hence, claim 30 is 
allowable. 

New dependent claims 33 and 35 recite that the input video stream is in a 
compressed digital format. In contrast, Guetz and Doty provide an analog input, as explained 
above, and therefore their input video is not compressed and is not digital. Liu is completely 
silent as to whether his input video is compressed or un-compressed. Claims 33 and 35 are thus 
allowable. 

New dependent claims 34 and 36 recite server features involving de-compressing 
the input video stream having the compressed digital format, and re-compressing into the 
multiple simultaneous output video streams. None of the cited references, whether singly or in 
combination, disclose, teach, or suggest the recited de-compressing/re-compressing, as well as 
the other features recited in claims 34 and 36 pertaining to the input video stream having the 
compressed digital format and the simultaneous output video streams. Accordingly, claims 34 
and 36 are allowable. 

New dependent claim 37 recites that the "simultaneous output video streams have 
different encoding formats including both an MPEG compression format and a non-MPEG 
format." Guetz does not provide this feature, and as explained above, Liu only addresses color 
encoding and makes no mention of MPEG/non-MPEG as well as compressing/non-compressing. 
Therefore, claim 37 is allowable. 
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VII. Rejoinder of withdrawn claims 

Claims 1-15 are currently withdrawn pursuant to a Restriction Requirement made 
final in the Office Action of November 3, 2003. In that Office Action, the Examiner indicated 
that he could determine/consider whether claim 1 6 is generic or not over the non-elected claims, 
if and when claim 16 becomes allowable. 

With the amendment introduced to claim 16 discussed above, it is believed that 
claim 16 is thus now in condition for allowance and that the generic nature of claim 16 was not 
changed due to the introduced amendment. Withdrawn independent claims 1 and 8 are amended 
herein to include recitations generally along the lines of some of the recitations contained in 
amended claim 16. 

Claim 16 is clearly generic over claims 1 and 8, since claim 16 recites code to 
"derive requirements for the output video streams" and code to "change characteristics of the 
frames," whereas claims 1 and 8 contain more specific recitations. Accordingly, the applicants 
request the rejoining and allowance of withdrawn claims 1-15. 

VIII. Conclusion 

Overall, none of the references singly or in any motivated combination disclose, 
teach, or suggest what is recited in the independent claims. Thus, given the above amendments 
and accompanying remarks, the independent claims are now in condition for allowance. The 
dependent claims that depend directly or indirectly on these independent claims are likewise 
allowable based on at least the same reasons and based on the recitations contained in each 
dependent claim. 

If the undersigned attorney has overlooked a teaching in any of the cited 
references that is relevant to the allowability of the claims, the Examiner is requested to 
specifically point out where such teaching may be found. Further, if there are any informalities 
or questions that can be addressed via telephone, the Examiner is encouraged to contact the 
undersigned attorney at (206) 622-4900. 

The Director is authorized to charge any additional fees due by way of this 
Amendment, or credit any overpayment, to our Deposit Account No. 19-1090. 
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All of the claims remaining in the application are now clearly allowable. 
Favorable consideration and a Notice of Allowance are earnestly solicited. 

Respectfully submitted, 
SEED Intellectual Property Law Group pllc 



Dennis M. de Guzman 
Registration No. 41,702 
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